Feautre/add input fields to searchbar #689

MatsJohansen87 · 2025-09-26T10:24:51Z

Description

Add input fields to Search bar

Related Issue

#498

How Has This Been Tested?

UI user test

…xpected

…n about behaviour

…ses focus

…is triggered This let the user know, that this input is not displayed in the current search.

src/components/buttons/SearchButtonComponent.wc.svelte

src/components/catalogue/AddButton.svelte

src/components/catalogue/DatePickerComponent.svelte

timakro · 2025-09-29T11:20:01Z

src/components/catalogue/DatePickerComponent.svelte

I think the DatePickerComponent should be less concerned with the search bar functionality.

To keep up/down arrow navigation functionality I think it would be fine to use a capture phase event handler (https://svelte.dev/tutorial/svelte/capturing) in the search bar drop down to intercept up and down arrows before they even reach the text input using event.stopPropagation(). For numbers this would be fine in my opinion. I don't consider the up/down arrow to increment/decrement numbers important. I hope the date picker calendar arrow key navigation would not break.

I think you could use a similar strategy for detecting focus without touching the DatePickerComponent. Or alternatively just add a onfocus prop to the DatePickerComponent and handle everything else outside of the component.

src/components/buttons/StoreDeleteButtonComponent.svelte

src/index.ts

timakro · 2025-09-29T11:44:23Z

eslint.config.js


 export default defineConfig([
-    globalIgnores(["dist", "book/book", "docs/assets"]),
+    globalIgnores(["dist", "book", "docs/assets"]),


Generally I would want to lint the book markdown files. Can we fix the issues without disabling linting of those files completely?

I agree. but book/book doesn't exist anywhere, so this was unnecessary, right?

When you install mdbook and build the book locally it generates the HTML files there.

src/types/queryData.ts

src/components/search-bar/SearchBarComponent.wc.svelte

monitor performance with big catalogues

timakro

The code in the search bar component looks much better now. And great that you added regex escaping to the search highlighting.

Do you think we can move some of the search bar and focus handling out of the input components? Maybe you can try my suggestion to intercept the arrow keys before the input components receive them. But I haven't thought a lot about that so I understand if you decide to stick with the current approach where you press escape to back out of the input component and then use the arrow keys.

timakro · 2025-10-02T14:06:24Z

src/components/search-bar/SearchBarComponent.wc.svelte

+    let inside: boolean = $state(false);
+
+    function handleClickInside(): void {
+        inside = true;
+    }
+
+    function handleClickOutside(): void {
+        if (!inside) {
+            autoCompleteOpen = false;
+        }
+        inside = false;
+    }


Are these click handlers needed? I tried without them and didn't noticed a difference

Should have handled the click onto an input element of the options but didn't work because the inside check was missing in handleFocusOut(). Added it and now it works as intended: when the click is outside the form elements but still inside of the input element it won't close.

timakro · 2025-10-02T14:07:11Z

src/components/search-bar/SearchBarComponent.wc.svelte

+    }
+
+    let searchBarContainer: HTMLElement;
+    let optionsList: HTMLUListElement;


This is unused

timakro · 2025-10-02T14:07:29Z

src/components/search-bar/SearchBarComponent.wc.svelte

+                            onmousedown={() =>
+                                addInputValueToStore(
+                                    inputOption,
+                                    extractTargetGroupFromInputValue(),
+                                )}


Does this do anything? The NumberInputComponent adds the item to the query itself.

…y one bar

MatsJohansen87 · 2025-10-06T10:19:06Z

Maybe you can try my suggestion to intercept the arrow keys before the input components receive them. But I haven't thought a lot about that so I understand if you decide to stick with the current approach where you press escape to back out of the input component and then use the arrow keys.

I'm always careful when it comes to altering browser native behaviour. the user will expect the form fields to work the same way throughout the application. if we make that change, the input will behave differently from the ones in the catalogue. also it's a behaviour known to users for as long as they use the internet 😅

But maybe the convenience for the user is high enough to make that change. I guess this would come down to a short user test. I will recruit some non-IT-people.

MatsJohansen87 · 2025-10-06T10:23:56Z

Do you think we can move some of the search bar and focus handling out of the input components?

I tried from the beginning and failed miserably 😄. 100% open to elegant solutions.

timakro · 2025-10-06T12:03:37Z

I'm always careful when it comes to altering browser native behaviour.

I agree. In this case I think it might be worth it to prioritize the arrow keys but I'm not dead set on it.

100% open to elegant solutions

I'd try to use a capture phase event handlers (https://svelte.dev/tutorial/svelte/capturing) on the input components to catch the focusin and keydown events. If this works you could have the event handling code in the search bar component and reuse the handler functions between the different input component types. This should also get rid of some callback props if it works.

patrickskowronekdkfz · 2025-10-13T11:29:38Z

@MatsJohansen87 could you check why this feature is not working on safari? On chrome it works fine

…of children

…tiple lines

…ood type

…ct shift tab behaviour

MatsJohansen87 · 2025-11-14T11:15:10Z

I think i found an elegant way to move the focus logic to the searchbar component itself. I also changed my mind about the idea to change the active element instead of increasing or decreasing the numbers in number and date inputs and think it's more intuitive like this. So i also implemented that.
Please have another look. I also found the bugs where the first chip wasn't displayed and pressing enter didn't work.

timakro

Good job on getting rid of two props on the input components and moving some of the logic to search bar. I think we could also move the remaining search bar code out of the input components by using capture phase event handlers. See my comments on the code for the detailed suggestions.

timakro · 2025-11-14T12:25:41Z

src/components/catalogue/NumberInputComponent.svelte

-    function onsubmit(event: SubmitEvent): void {
-        event.preventDefault();
+    function addItem(): void {
+        if (!formVlaid) {


Instead of computing validity yourself use the return value of reportValidity() here. This will include validation of built-in HTML attributes like required, min, max and the custom errors you set with setCustomValidity. Right now for example the min HTML attribute does not work and it is possible to add body weight rage -40 through -10 in the demo.

timakro · 2025-11-14T12:28:23Z

src/components/catalogue/StringInputComponent.svelte

+    function validateForm(value: string | null): boolean {
+        input.setCustomValidity("");
+        if (!value) {
+            input.setCustomValidity(translate("cannot_be_empty"));


See my comment on NumberInputComponent. You could use required HTML attribute instead of custom validation.

timakro · 2025-11-14T12:32:48Z

src/components/catalogue/NumberInputComponent.svelte

    let {
        element,
+        inSearchBar = false,
+        resetToEmptySearchBar = () => {},


To decouple this from the search bar I think it would be nicer to expose an event handler onItemAdded here and then register the callback from outside:

<NumberInputComponent onItemAdded={resetToEmptySearchBar}>

timakro · 2025-11-14T12:43:32Z

src/components/catalogue/NumberInputComponent.svelte

+    function onkeydown(event: KeyboardEvent) {
+        if (inSearchBar === false) return;
+
+        if (event.key === "Enter") {
+            addItem();
+        }
+
+        if (event.key === "ArrowUp" || event.key === "ArrowDown") {
+            event.preventDefault();
+        }
+    }
+
+    function onfocusin(event: FocusEvent) {
+        if (!inSearchBar) return;
+        // toInput can not be reached by tab when the focus is outside the form,
+        // so this can handle the focus via mouse click instead of using another event listener
+        if (event.target === toInput) return;
+
+        const relatedTargetOutside =
+            event.relatedTarget instanceof Node &&
+            !form.contains(event.relatedTarget);
+
+        if (relatedTargetOutside) {
+            fromInput.focus();
+        }


Instead of handling these in the input components could you try my suggestion of handling them completely from the search bar using capture phase event handlers (https://svelte.dev/tutorial/svelte/capturing)?

For the enter key you can expose addItem to the outside.

The arrow keys are already handled from the outside if you now also call event.preventDefault() during the capture phase the input won't see the arrow key event so no need to ignore it here.

I'm not 100% sure about the focus logic but it seems it is already partially handled outside. I think it would be fine if you drill down to the first input element with a smart query selector from the outside and just focus that.

timakro · 2025-11-14T12:46:31Z

src/components/buttons/SearchButtonComponent.wc.svelte

    const onclick = (): void => {
        queryModified.set(false);
        window.dispatchEvent(new CustomEvent("lens-search-triggered"));
+        window.dispatchEvent(new CustomEvent("reset-all-searchbar-inputs"));


Currently only NumberInputComponent seems to respect this. Do we even need this as when search button is pressed the search bar should loose focus and thus all inputs should be destroyed and therefore their contents reset?

timakro · 2025-11-14T12:49:28Z

src/components/search-bar/SearchBarComponent.wc.svelte

        return index;
    };

+    let searchBarInputHasFoucs = $state(true);


Suggested change

let searchBarInputHasFoucs = $state(true);

let searchBarInputHasFocus = $state(true);

timakro · 2025-11-14T12:53:15Z

src/components/search-bar/SearchBarComponent.wc.svelte

+        let focusedListItem = optionElements.find(
+            (element) => element && element.matches(":focus-within"),
+        );
+        if (focusedListItem) {
+            focusedItemIndex = optionElements.indexOf(focusedListItem);
+        }


Seems like something that could better go on the input component like

<NumberInputComponent onfocusin={() => focusedItemIndex = myIndex}>

If you add a capture phase event handler onfocusincapture on the input components like I suggested it would go in there I suppose.

patrickskowronekdkfz

Except some of the comments of @timakro the rest is fine

MatsJohansen87 added 10 commits September 23, 2025 10:58

feat(searchbar): add number inputs

69e2dd7

feat(searchbar): add date inputs

955fcd1

feat(searchbar): add string inputs

10d97ab

chore(input components): remove unnessesary check

3ee3fdb

fix(searchbar focus): clicking and focusing in and out now works as e…

256215a

…xpected

fix(search bar options): remove pointer from inputs to avoid confusio…

f5d4a0c

…n about behaviour

fix(searchbar focus): handle long pressed tab correctly, when bar loo…

b44663d

…ses focus

feat(search bars): add deleting inputs as default option when search …

c009195

…is triggered This let the user know, that this input is not displayed in the current search.

feat(search bar): add more style options and update book

483e55a

Merge branch 'develop' into feautre/add-input-fields-to-searchbar

8b9d9dd

MatsJohansen87 self-assigned this Sep 26, 2025

MatsJohansen87 requested review from patrickskowronekdkfz and timakro September 26, 2025 11:12

timakro requested changes Sep 29, 2025

View reviewed changes

MatsJohansen87 added 5 commits October 2, 2025 10:31

refactor(searchbar): add less hacky solution for searchbar behaviour

b946394

fix(searchbar regex): prevent crash from unescaped characters

6616f39

fix(searchbar): start with 2 letters to get blood type 'a+' etc

81cb154

monitor performance with big catalogues

fix(searchbar): clear bars on search and remove export

5f3bf71

chore(query types): restrict autocomplete field type to criterion

2d26683

timakro reviewed Oct 6, 2025

View reviewed changes

MatsJohansen87 added 2 commits October 6, 2025 12:07

fix(searchbar): handle click inside properly

fbae9b5

fix(searchbar delete button): remove input on click when there is onl…

fa46fb9

…y one bar

MatsJohansen87 added 4 commits November 14, 2025 11:19

feat(searchbar): handle focus and tab behaviour in searchbar instead …

26e58d1

…of children

fix(autocomplete): fix misplaced autocomplete when search bar has mul…

2126bf2

…tiple lines

feat(typeMoreMessage): translate and reduce to capture things like bl…

5ccd803

…ood type

chore(string input): remove unnessesary functions

f07a4df

MatsJohansen87 added 2 commits November 14, 2025 12:11

fix(number,string): inputs add value on enter correctly

085c4fa

fix(searchbar): remove bug where first chip isn't shown and add corre…

1d6c18b

…ct shift tab behaviour

MatsJohansen87 requested a review from timakro November 14, 2025 11:15

timakro reviewed Nov 14, 2025

View reviewed changes

MatsJohansen87 added 3 commits November 18, 2025 11:30

chore(search bar): get elements directly without css selector

2b0f660

fix(searchbar): correct tab backwards behaviour

1e52226

feat(searchbar): add workaround behaviour for safari

82b16b9

patrickskowronekdkfz approved these changes Nov 19, 2025

View reviewed changes

timakro approved these changes Nov 19, 2025

View reviewed changes

MatsJohansen87 added 2 commits November 19, 2025 14:41

Merge branch 'develop' into feautre/add-input-fields-to-searchbar

2879ce4

fix(demo): remove system

846d7a4

MatsJohansen87 requested a review from patrickskowronekdkfz November 19, 2025 14:21

patrickskowronekdkfz approved these changes Nov 19, 2025

View reviewed changes

MatsJohansen87 merged commit a1955bf into develop Nov 20, 2025
4 checks passed

	let searchBarInputHasFoucs = $state(true);
	let searchBarInputHasFocus = $state(true);

Feautre/add input fields to searchbar #689

Feautre/add input fields to searchbar #689

Uh oh!

Conversation

MatsJohansen87 commented Sep 26, 2025

Description

Related Issue

How Has This Been Tested?

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

timakro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MatsJohansen87 commented Oct 6, 2025

Uh oh!

MatsJohansen87 commented Oct 6, 2025

Uh oh!

timakro commented Oct 6, 2025

Uh oh!

patrickskowronekdkfz commented Oct 13, 2025

Uh oh!

MatsJohansen87 commented Nov 14, 2025

Uh oh!

timakro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patrickskowronekdkfz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants